IBIS Macromodel Task Group Meeting date: 09 February 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. -------------------------- Call for patent disclosure: - None. ------------- Review of ARs: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Bob M.: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Fixing [Pin Mapping]: - Walter: I think this can be removed from the agenda. - We are handling it in the interconnect task group meetings. - Arpad: I am okay with that. - Does anyone have any comments on removing this from the agenda? [none] - I will remove it. New Redriver Flow BIRD: - Arpad/Walter: Not worth discussing today without Fangyi here. Discussion of language corrections regarding "ground": - Discussion: Walter said he thought we had generally agreed in last week's meeting that the IBIS spec's use of ground was largely okay with respect to a device under test (DUT) and measurement of data (test bench or simulation). He said that we needed to fine tune wording and clarify the context of some of the sections, but that this could be dealt with in an editorial task group. He noted that Radek had expressed a desire to go further and clarify certain concepts with respect to a device in action as opposed to just the DUT. He said he had no objections to that, but didn't think it was necessary. Radek agreed with Walter's suggestion, and confirmed that he would want to be a part of the editorial task group. He suggested that task group could work on clarifying the ground language to create IBIS 6.2, and also could produce additional BIRDs for reference node clarifications, etc., as necessary. Walter agreed that topics might come back to the ATM group if necessary. Bob agreed with Walter's suggestion and confirmed his interest in working with the editorial task group. Mike L. and Arpad raised some logistical questions, and confirmed that Michael M. had served as chair and editor-in-chief for previous editorial task group projects. Michael M. agreed to serve in both roles again this time. The editorial task group typically meets on the Fridays when there is no Open Forum meeting. Radek said he would be extremely busy for the next two weeks and unable to start on this task. Arpad suggested that the inaugural editorial task group meeting be scheduled for March 4th, the Friday after the next Open Forum meeting. Everyone agreed with this, and Michael Mirmak took the action item to send out a kickoff announcement email to the IBIS lists. How to handle missing min/max data?: - Arpad: I have no updates on this topic and haven't had time to work on it. - Walter had some new thoughts he wanted to share. - Walter: After studying the ground language, my understanding of IBIS is that, at least for legacy models, IBIS only talks about how to measure I/V, and v(t) and Composite Currents (measure, again meaning test bench or simulation). - Everything is relative to a reference node and based on measurement. - Therefore, all of the parameters are based on measurement. - So when some parameter only has a typ value, does that mean they only measured it under typ conditions, or they only have one value? - You're normally measuring three devices, a typ, min, and max device. - Implication is that threshold parameters, etc., are all derived from those measurements. - If you have Vinl, Vmeas, etc., and only have a typ value, what is it for? - Is it the same value for the min, typ, and max DUT? - Or, is it only for the typ DUT. - My interpretation is the typ value is also for the min and max DUT. - If you have a min value for a parameter, did it come from measuring the min device or the max device? - IBIS has to tell you how to measure things, so I think we have to go ahead for each parameter and say what it means to only have a typ value, because it's a measurement specification not a usage specification. - I think Arpad wrote up this topic as "How do you use something?" - I don't think IBIS should tell you how to use data, it should tell you how they were measured. - Arpad: When I started thinking about this issue, it was raised by the question of how the simulators would use the data. - But it was also triggered by some statements in the spec that say you should use the typ value for min and/or max if those columns contain NA. - At that point we had never had any discussion regarding normative vs. informative, so I thought the spec was actually giving instructions on how to use the data or what to do if min and max data were missing. I thought those were normative instructions. - Now Walter is indicating that since IBIS is a measurement spec and really shouldn't be mentioning how things are used, any of mention of how to use things is informative not normative. - Bob: We already have voltage sensitive specifications. - In [Model Spec], where we have typ, min, max, there are parameters that allow for the explicit declaration of specification thresholds as they vary with the voltages. - Discussion: Walter agreed with Bob's point regarding [Model Spec]. However, they had different opinions on how data for the subparameters might be obtained. Walter described some measurement scenarios to determine the relationships between the parameters (e.g., a threshold varying with rail voltage), but Bob said they were created with the expectation of holding ranges from data sheet values. Walter said both were valid interpretations, and that since typ, min, max would mean different things depending on the interpretation even this suggested the IBIS spec had to more carefully define the way each IBIS parameter was measured. He said that the question of missing min max data was secondary to the question of exactly how to handle min max data if you did have it. Arpad raised the point of this new suggestion that IBIS was only a measurement spec and asked if we were really moving forward with this approach. Radek again pushed back on the idea, and again suggested that IBIS both defined the measurements and defined things that were necessary for unambiguously creating a useful behavioral model. Arpad then said that we needed to resolve this larger question in order to tackle this specific topic of missing min max data. He said there were some inconsistencies in the spec currently, as it said to use the typ value for missing min max data in some places but not others. He also pointed out that using typ raised many additional questions, as you might run into trouble if you only had typ v(t) curves but had typ, min, and max I/V tables, for example. All the combinations and possibilities were not spelled out, and the statements about using typ might be incorrect or misleading. The question of ranges was discussed, with Arpad wondering if ranges implied specification limits (absolute bounds on behavior) or statistical chip behaviors (e.g., 3 sigma bounds). Radek pointed out that he thought the spec said only the typ, min or max values are to be used and not values in between them. Arpad did not think the spec prohibited this. K(t) tables were also discussed, as an example of something most simulators do without explicitly being told to by the IBIS spec. After these discussions of various concepts that might be vaguely specified and require clarification, and whether the spec should ever tell the EDA tool what to do with data, Arpad took the AR to go through the spec and find all instances where typ was stated as serving as the default for missing min and max data. Note: Radek had to leave the call at this point. Buffer Impedance / C_comp improvements: - Walter moved to untable the topic. - Randy seconded. No one was opposed. - Walter: In private discussion with Randy and Michael M., we've discussed the idea of adding the IBIS b-element (HSPICE b-element) to IBIS ISS. - Understanding that ISS currently stands for interconnect SPICE subcircuits, set that aside for now. - If we take the b-element and use External Model to add whatever one wanted as a C_comp compensation as IBIS ISS elements, it might be an alternative to adding a SPICE subcircuit for C_comp in our legacy IBIS models. - Arpad: I think I would be in favor of that. - Would we have to ask Synopsys for permission to do so? - Walter: I would ask them. I don't think it will be a problem. - Their b-element is quite complicated. - All we need is a basic subset of it (file, model, ports). - There is one issue with handling the effects of the C_comp circuit. - We know how hard it can be to generate the K(t) function, even with a regular C_comp, because the v(t) data might not be well measured. - One idea Randy and I came up with is to have the model maker give a C_comp effective that the tool uses to generate its K(t) curves, then the tool can apply those K(t) curves using the more complicated actual C_comp compensation circuit. - I wanted to introduce those concepts. I could put together more thoughts on this for next week. - Arpad: Thank you all for joining. AR: Michael M. to send out a kickoff email for editorial task group meetings starting on March 4th. AR: Arpad to review the spec and find all instances of language stating that the typ value should serve as the default for missing min max values. ------------- Next meeting: 16 February 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives